Reviewing files that changed from the base of the PR and between 770aeff and 59df482.

• .changeset/fluffy-emus-burn.md (1 hunks)
• packages/eslint-config/src/configs/javascript.ts (1 hunks)
• packages/eslint-config/src/configs/react.ts (1 hunks)
• packages/eslint-config/src/factory.ts (2 hunks)

.changeset/fluffy-emus-burn.md (1)

1-5: LGTM: Changeset captures the intent correctly

The changeset correctly documents that react/no-leaked-conditional-rendering rule is being temporarily disabled due to a parserOptions issue, with the intention to re-enable it once the issue is resolved.

packages/eslint-config/src/configs/react.ts (1)

172-172:

✅ Verification successful

Appropriate temporary solution with clear documentation

The rule react/no-leaked-conditional-rendering has been properly commented out with a clear comment explaining why it's disabled (parserOptions issue). This aligns with the changeset and PR objectives.

---

🌐 Web query:

What are the requirements for the ESLint rule "react/no-leaked-conditional-rendering" to work properly?

💡 Result:

The ESLint rule react/no-leaked-conditional-rendering (also known as no-leaked-conditional-rendering in ESLint React or jsx-no-leaked-render in eslint-plugin-react) is designed to prevent problematic leaked values from being rendered in React components. This rule helps developers avoid unexpected rendering behavior that can occur when using the && operator for conditional rendering.

Rule Purpose

The rule targets a common issue in React development where using the && operator for conditional rendering can lead to unwanted values being displayed or even application crashes[1][2]. For example, values like 0, NaN, or empty strings can "leak" into the rendered output when they're on the left side of an && expression[4].

In React Native, this issue is even more severe as rendering these leaked values can crash the application entirely[1][7].

Configuration Requirements

To use this rule effectively, you need to:

1. Install the appropriate ESLint plugin:

   • Either eslint-plugin-react (where the rule is called jsx-no-leaked-render)
   • Or @eslint-react/eslint-plugin (where it's called no-leaked-conditional-rendering)[1][2]

2. Configure the rule in your ESLint config:

   {
     "rules": {
       "react/jsx-no-leaked-render": ["error", { "validStrategies": ["ternary", "coerce"] }]
     }
   }

   Or for the ESLint React version:

   {
     "rules": {
       "no-leaked-conditional-rendering": "error"
     }
   }

3. Understand the rule options:

   • The rule accepts a validStrategies option that can include "coerce", "ternary", or both (default is ["ternary", "coerce"])[2]
   • The order of strategies matters for autofix behavior, with the first one being used when fixing issues[2]

Valid Strategies

The rule supports two main strategies for preventing leaked renders:

1. Coerce strategy: Transforms expressions by coercing values to booleans

   • Uses !!value or Boolean(value) to ensure boolean conversion
   • Example: {!!count && <Component />}[2][4]

2. Ternary strategy: Uses ternary expressions instead of &&

   • Example: {count ? <Component /> : null}[2][4]

Examples of Issues Caught by the Rule

The rule will flag code like:

// Problematic code
const Component = ({ count, title }) => {
  return <div>{count && title}</div>
}

This is problematic because if count is 0 or NaN, it would render those values instead of nothing[2][4].

Recommended Fixes

Depending on your configuration, the rule will suggest:

1. Using boolean coercion:

   const Component = ({ count, title }) => {
     return <div>{!!count && title}</div>
   }

2. Using ternary operators:

   const Component = ({ count, title }) => {
     return <div>{count ? title : null}</div>
   }

With autofix enabled, the rule can automatically transform your code to follow these patterns[2][4].

Integration with TypeScript ESLint

While this rule isn't part of the TypeScript-ESLint ecosystem directly, there have been proposals to integrate similar functionality with TypeScript's type checking to make the rule even more powerful[7]. Some developers use this rule alongside TypeScript's strict-boolean-expressions rule for more comprehensive protection.

I hope this helps clarify how to use the no-leaked-conditional-rendering rule effectively in your React projects.

Citations:

• 1: https://eslint-react.xyz/docs/rules/no-leaked-conditional-rendering
• 2: https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/jsx-no-leaked-render.md
• 3: jsx-eslint/eslint-plugin-react#3441
• 4: https://dev.to/maafaishal/avoid-operator-for-conditional-rendering-in-react-2de
• 5: https://eslint-react.xyz/docs/rules/no-complex-conditional-rendering
• 6: https://dev.to/timwjames/the-best-eslint-rules-for-react-projects-30i8
• 7: typescript-eslint/typescript-eslint#2770
• 8: https://timjames.dev/blog/the-best-eslint-rules-for-react-projects-30i8
• 9: https://www.npmjs.com/package/eslint-plugin-jsx-no-leaked-values
• 10: typescript-eslint/typescript-eslint#10705

---

Approved: Temporary disable of react/no-leaked-conditional-rendering is well-documented
The comment clearly explains that this rule is disabled due to parserOptions limitations. As a reminder, this rule requires:

• Installing and enabling the correct plugin (eslint-plugin-react or @eslint-react/eslint-plugin)
• Enabling JSX parsing via parserOptions.ecmaFeatures.jsx = true (or equivalent)
• Configuring the rule (e.g. "react/jsx-no-leaked-render": ["warn", { validStrategies: ["ternary","coerce"] }])

Once the parserOptions issue is resolved, re-enable the rule with your preferred strategy settings.

packages/eslint-config/src/configs/javascript.ts (1)

57-57: Enhanced console logging configuration

The no-console rule has been updated to allow console.info in addition to the previously allowed warn and error methods. This change aligns with the use of console.info in the factory.ts file.

packages/eslint-config/src/factory.ts (1)

110-110: Logging updated to use console.info

Changed from console.log to console.info, which aligns with the updated ESLint rule configuration that now allows console.info.